Many software applications involve multiple requesters seeking access to a shared resource. For example, an airline reservation system concurrently processes reservation requests on behalf of the travelers seeking to travel the routes serviced by the airline. Database management system (DBMS) software underlies the application software and controls access to the shared data resources in order to maintain database consistency. For other types of applications, underlying system software similarly controls access to data objects that are shared by multiple requesters.
System performance may be improved in multi-requester applications by supporting concurrent processing of multiple requests. The system protects against data inconsistency by allowing only one requester at a time to change the data of a particular object. This control may be implemented by way of lock control structures, timestamps, or semaphores, for example. The system also detects deadlock situations and suitably undoes any partially completed requests.
The data of a relational database is often viewed as one or more tables. Each row of the table may be viewed as a record that contains logically related data elements, which are defined by the columns. Within the database, the DBMS maintains the data in one or more files. Each of the files is divided into pages, and each page contains one or more records.
One of the hallmarks of DBMSs is the ability to ensure that updates persist across both hardware and software failures. This capability is typically enabled using a log or audit trail which contains information about each incremental update to the database as made by each transaction.
DBMSs generally take two approaches to create the incremental update information. In the first approach, the DBMS takes a snapshot of the updated page after it has been updated by the modifying transaction. The contents of the entire page are stored in a record in the audit trail. In the second approach, the DBMS stores a copy of the modifying operation (INSERT, UPDATE, or DELETE) in an audit record.
When a failure occurs, the database administrator uses a recovery utility to restore the database to a consistent state. With the first approach, the recovery utility reads the contents of pages from the audit trail and writes the page data to the database file in timestamp order. With the second approach, the recovery utility, in conjunction with the DBMS, replays the database modifications, in timestamp order. For discussion purposes, the first approach provides “page level” auditing and recovery, and the second approach provides “record level” auditing and recovery.
An advantage of page level recovery is that the recovery operation can be done very quickly without intervention by the DBMS. A disadvantage is that the DBMS must have exclusive access to the page at the time the page snapshot is written to the audit trail and must maintain the exclusive access until a COMMIT point of the transaction. This prevents other update transactions from accessing the page, thereby reducing concurrency. An advantage of record level recovery is that the DBMS requires exclusive access only to the specific record at the time the modifying operation is written to the audit trail and maintains the exclusive access, only to the record, until a COMMIT point. Thus, for record level auditing other transactions may access other records on the page. A disadvantage of record level recovery is that during a recovery operation, the DBMS must reapply each modification individually, which can be very time consuming.
A method and system that address these and other related issues are therefore desirable.